Security element commanding method and mobile terminal

ABSTRACT

The invention relates to a method for commanding a security element of a mobile terminal, and to a mobile terminal. An installed application of the mobile terminal issues a command to a platform library of the mobile terminal. Then the platform library reads information from an access control file of the security element. After this, the platform library obtains an access code for the security element from a user according to the access control file information, and inputs the obtained access code and the command to the security element. An action is performed according to the command in the security element, if the access code is approved by the security element.

FIELD

The invention relates to a method for commanding a security element of amobile terminal, and to a mobile terminal.

BACKGROUND

With the opening of the software environment of the mobile terminal andwith the 3G (Third Generation) specifications, it is becoming possiblefor third parties (including cellular operators and mobile terminalmanufacturers) to make applications for mobile terminals that handle thesecurity element, usually a smart card, in the terminal. An applicationthat is installed in the mobile terminal by the user can be called aninstalled application. The applications that reside more permanently inthe mobile terminal are usually installed into the mobile terminal bythe manufacturer when the device is manufactured, and are called aplatform library. Throughout this application, we use these two terms:the installed application and the platform library. Usually, the userinstalls the installed application in the mobile terminal after s/he hasacquired the mobile terminal, whereas the manufacturer installs theplatform library or part thereof in the mobile terminal before the saleof the mobile terminal to the end-customer.

The Java™ Community Process (JCP) expert group defines a Java™programming environment for mobile terminals and security elements in aspecification called JSR-177 (Java™ Specification Request 177). Becauseinstalled applications, such as Java™ midlets, can be loaded into aterminal from multiple sources, and the security environment for thoseapplications differs from the security environment of the securityelement, there needs to be a mechanism with which the security elementapplication can define the installed applications that can invokecommands on the security element application.

The installed application can be signed, and the mobile terminal willverify the signature and thus the origin of the installed application.The mobile terminal can have separate restrictions on applicationscoming from cellular operators, manufacturers and others. So the issuerof the application signs the midlet, the mobile terminal verifies thesignature and if the signature is that of the cellular operator, themidlet gets the rights specified for that security domain (for examplecan make a phone call, can access the security element, but cannot writeto the mobile terminal operating system area).

The mobile terminal security element, such as a SIM (Subscriber IdentityModule) or USIM (UMTS SIM) card, a security element of the terminalitself or a security element in an accessory of the terminal, is neededfor secure storage and processing of data. Digital signature creation,for example, requires a very secure element in which to do theoperation, because a private key cannot be compromised, and thus theprivate key cannot leave the security element. Other usages for securityelements are access authentication to networks, storing electronic cashvalues or tickets, or processing financial transactions. So there is aneed for installed applications to access the security element for theseadvanced features.

The basic problem is that the application running in the securityelement cannot itself verify that the installed application accessing ithas the appropriate rights and is a valid application. The cellularoperators want to limit SIM access to applications coming from theoperators themselves. An attacking application can fake a security codefor access granting, and it is not possible to transfer the wholeinstalled application to the security element for verification (indeedit might be so that a valid application is given for verification butthe attacking application uses the element after access granting).

BRIEF DESCRIPTION

An object of the invention is to provide an improved method forcommanding a security element of a mobile terminal.

According to an aspect of the invention, there is provided a method forcommanding a security element of a mobile terminal, the methodcomprising: issuing a command to a platform library of the mobileterminal by an installed application of the mobile terminal; readinginformation from an access control file of the security element by theplatform library; obtaining an access code for the security element froma user according to the access control file information by the platformlibrary; inputting the obtained access code and the command to thesecurity element by the platform library; and performing an actionaccording to the command in the security element, if the access code isapproved by the security element.

Another object of the invention is to provide an improved mobileterminal.

According to another aspect of the invention, there is provided a mobileterminal, comprising a platform library; an installed application; auser interface; and a security element; the installed application beingconfigured to issue a command to the platform library; the platformlibrary being configured to read information from an access control fileof the security element, to obtain an access code for the securityelement from a user via the user interface according to the accesscontrol file information, and to input the obtained access code and thecommand to the security element; and the security element beingconfigured to perform an action according to the command, if thesecurity element approves the access code.

Embodiments of the invention are described in the dependent claims.

The invention provides several advantages. The mobile terminal does notneed to know the properties of a particular security element, thus onemobile terminal can use a variety of different security elements as longas they include an access control file with the information used for theaccess code obtainment. The security of the mobile terminal is increasedas the installed applications cannot directly handle the securityelement and the access code. The invention allows the security elementto define its own security perimeter.

LIST OF DRAWINGS

In the following, the invention will be described in greater detail withreference to the preferred embodiments and the accompanying drawings, inwhich

FIG. 1 is a simplified block diagram illustrating the structure of amobile terminal;

FIG. 2 illustrates the structures of a control unit and securityelement; and

FIG. 3 is a signal sequence chart illustrating a method for commanding asecurity element of a mobile terminal.

DESCRIPTION OF EMBODIMENTS

With reference to FIG. 1, an example of the structure of a mobileterminal 100 is described. The mobile terminal 100 can be a portabledevice relating to ubiquitous computing, for instance a subscriberterminal in a radio system, such as a mobile system, a PDA (PersonalDigital Assistant) device, or another electronic device incorporating asecurity element 106 to its operation. The device may also combinevarious roles, i.e. it may for example be a combination of a subscriberterminal and a PDA device, the Nokia® Communicator® being one example ofsuch devices.

In our example, the mobile terminal 100 is a subscriber terminal in aradio system, the mobile terminal 100 comprising an antenna 110 and aradio transceiver 108. The mobile terminal 100 is capable ofestablishing a two-way radio connection 112 with the network part 114 ofthe radio system. The radio transceiver 108 is for example a prior-artmobile station transceiver, which operates for example in the GSM(Global System for Mobile Communications) system, GPRS (General PacketRadio Service) system or UMTS (Universal Mobile TelecommunicationsSystem).

A typical mobile terminal 100 comprises as its user interface 104, whicha user 120 of the mobile terminal 100 used for interaction with it, thefollowing components: a keypad, display, microphone and loudspeaker. Thepower source of the mobile terminal 100 is generally a rechargeablebattery.

The mobile terminal 100 comprises a control unit 102, which controls andmonitors the operation of the terminal and the various parts thereof.Currently, the control unit 102 is generally implemented as a processorwith software, but different hardware implementations are also possible,such as a circuit made of separate logic components, or one or moreapplication-specific integrated circuits (ASIC). A combination of thesedifferent implementations is also possible. When selecting animplementation, a person skilled in the art considers, for example, therequirements set for the size and power consumption of the device,necessary processing performance, manufacturing costs and productionvolumes.

Next, with reference to FIG. 2, the structures of the control unit 102and the security element 106 are illustrated. The control unit 102comprises installed applications 200, 202 and a platform library 204.The security element 106 comprises security element applications 208,212, and access control files 206, 210, 214.

The user 120 of the mobile terminal 100 can install one or moreinstalled applications 200, 202 in the mobile terminal, after s/he hasacquired the mobile terminal 100. The user 120 can, for example,download the installed application from a server 118 via the Internet116 and the network part 114 of the radio system, as illustrated inFIG. 1. The server 118 can be a WWW-server (World-Wide Web), forexample. The installed application 200, 202 is written in a programminglanguage. One example of such a language is the Java™ programminglanguage. JCP has developed the MIDP (Mobile Information Device Profile)architecture especially for mobile terminals. The programmingenvironment is called J2ME™ (Java™ 2 Platform MicroEdition). In the MIDParchitecture, the lowest level is the hardware of the mobile terminal100. On top of the hardware is the native system software that comprisesan operating system and a Java™ virtual machine. The operating systemcan be the Symbian™ operating system, for example. The manufacturer oroperator installs the platform library 204 or part thereof in the mobileterminal 100 before the sale of the mobile terminal 100 to theend-customer. Thus in the MIDP architecture, the platform library 204provides an interface, also known as API (Application ProgrammingInterface), to the services provided by the native system software. Inthe MIDP architecture, the installed applications 200, 202 can bewritten in the Java™ programming language and they can be called midlets(cf. an applet in Java™).

The security element 106 is used for the secure storage and processingof data. The data in the security element 106 can be accessed and/orprocessed by issuing commands to the security element 106. Some commandscan be such that they do not need an access code in order to beperformed. Usually, due to the confidential nature of the data stored inthe security element 106, the command must be accompanied with an accesscode provided by the user 120. The access code is usually a secret codeor password. The access code is sometimes called a PIN (PersonalIdentification Number) code.

Commands to the security element 106 needing the access code are, forexample: digital signature creation, access authentication to a network,storage of electronic cash values or a tickets, financial transactionprocessing. The installed application 200 is configured to issue acommand to the platform library 204. The platform library 204 isconfigured to read information from an access control file 206 of thesecurity element 106. Access control file information comprises accesscode usage instructions. Each application 208, 212 in the securityelement 106 has an access control file 206, 210 of its own, or anapplication in the security element 106 can also use a common accesscontrol file 214 of the security element 106. If the access control file206 of the A1 application 208 of the security element 106 defines thatan access code is needed in order to perform the command issued to theplatform library, then the platform library 204 is configured to obtainthe access code for the security element 106 from the user via the userinterface 104 according to the access control file 206 information.Having received the access code, the platform library 204 is configuredto input the obtained access code and the command to the securityelement 106. The input of the obtained access code and the command canbe combined in one message or method call or another suitable mechanismto pass the information between the platform library 204 and thesecurity element 106, or the input can be done separately by firstgiving one of the two and then giving the other.

The security element 106 is configured to perform an action according tothe command, if the security element 106 approves the access code. Inour example, this can be implemented so that the A1 application 208receives the access code, checks that the access code matches the accesscode known by the application 208 or known by the security element 106,and performs the action according to the command, if the match isconfirmed.

In an embodiment, the user interface 104 is configured to prompt theuser for the access code with prompt information stored in the accesscontrol file 206. This embodiment enables the platform library 204 tohandle the access code obtainment in a general way, without knowing thedetails. Another advantage is that the general appearance of the accesscode query always looks the same, so that the user 120 easily identifiesthat now confidential information is asked for.

In an embodiment, the user interface 104 is configured to display usageinformation on the access code usage stored in the access control file206. This embodiment informs the user 120 why the access code is needed.If the displayed information is not consistent with the user's mentalimage of the usage, then s/he can identify a possibly maliciousinstalled application that s/he can destroy from the memory of themobile terminal 100.

In an embodiment, the user interface 104 is configured to display helpinformation stored in the access control file 206. If the user 120 isuncertain, the help information can give confidence in the use ofsensitive information and also aid in understanding which commands arepossible at a certain stage.

In an embodiment, the platform library 204 is configured to downloadinformation complementary to the access control file 206 informationfrom a server 118 identified by a network address stored in the accesscontrol file 206. Usually this server 118 is the same as where theinstalled application 200 was downloaded from, but naturally it can alsobe another server. The platform library 204 can be configured tovalidate the complementary information with a security certificatestored in the access control file 206. This is done for securityreasons, so that the complementary information would not contain anyharmful or malicious parts, such as viruses. The platform library 204can also be configured to store the complementary information in thesecurity element 106 and/or in the mobile terminal 100, so that if thesame complementary information is needed in the future, it need not bedownloaded again.

In an embodiment, the complementary information is in a differentlanguage than the information stored in the access control file 206.This embodiment makes it possible to adjust the needed memory capacityof the security element, as perhaps only some language versions arestored in the access control file 206, and other language versions aredownloaded only as needed.

In an embodiment, the access control file information, i.e. prompt textinformation, usage text information and help text information, comprisesa code, and the actual information item such as the text correspondingto the code is stored in the platform library 204 and/or in a server 118identified by a network address stored in the access control file 206.This embodiment saves the memory of the security element 106, asdifferent applications may use the same information item which is onlystored once in the platform library 204.

With reference to FIG. 3, a method for commanding a security element ofa mobile terminal is explained. The method starts by issuing 302 acommand to a platform library 204 of the mobile terminal by an installedapplication 200 of the mobile terminal. According to the above-mentionedJSR-177, the platform library can support two types of connections: anAPDU (Application Protocol Data Unit) connection and a Java™ Card RMI(Remote Method Invocation) connection. If APDU is used, then theinstalled application 200 can use a command that is as follows, forinstance:

PerformSecurityElementCommand(command, command data) {

Library internal operation for application access rights verification;

Library internal operation for user prompting;

Library internal operation for command parsing;

Library internal operation for making command call to security element;

Library internal operation for reading security element response;

Library internal operation for giving response to installed application;

}

RMI could offer to the installed application 200 a method, such asdeduct_account(int amount), that would then be sent to the securityelement 106 with the described APDU command, for example.

These are, however, only examples of the command structure, and otherkinds of commands can also be used, and besides a method call also amessage interface can be used.

Next, in a optional operation, the platform library 204 checks 304 theaccess rights of the installed application to the security element byverifying if the installed application has the right to call thesecurity element application 208. The platform library 204 reads thecertificate for installed application verification from the accesscontrol file 206. The digital signature of the installed application 200is verified 306 with the certificate. In our example, the verificationsucceeds and the installed application is thus authenticated.

Then the platform library 204 reads 308 information from an accesscontrol file 206 of the security element. In our example, the accesscontrol file information defines that an access code is needed in orderto carry out the command 302. So for example PIN is used with command0x02 (transaction authorization). The access control file informationcan also indicate how the access code is given in the command (forexample, is it a parameter 1, parameter 2, or data part of the command,or is it a separate command 0x01 issued before command 0x02). The accesscontrol file information thus comprises access code usage instructions.As shown, the access control file 206 can be read two times by theplatform library 204, in 304 and 308. An embodiment is also possible,wherein the access control file 206 is read only once, before theverification 306 and the access code obtainment 312.

In an embodiment, information complementary to the access control fileinformation is downloaded 310 from a server 118 identified by a networkaddress stored in the access control file. The complementary informationcan be validated with a security certificate stored in the accesscontrol file. The complementary information can be stored in thesecurity element and/or in the mobile terminal. In an embodiment, thecomplementary information is in a different language than the accesscontrol file information. In an embodiment, the access control fileinformation comprises a code, and the actual information itemcorresponding to the code is stored in the platform library and/or in aserver identified by a network address stored in the access controlfile.

Next, the platform library 204 obtains 312 an access code for thesecurity element from the user 120 according to the access control fileinformation. Depending on the technology used, the access code can berealized according to the prior-art ways: a PIN code, password,acceptance indication (such as pressing an OK key for low security levelitems, such as a phonebook stored in the security element), or biometricauthentication (such as fingerprint reading, protein scan, heat and/orpressure characteristics of finger or palm pressure, etc.).

In an embodiment, the access code is obtained by prompting the user forthe access code with prompt information stored in the access controlfile. The prompt information can define that a prompt text “For networkauthentication” is displayed to the user. The obtaining 312 can alsocomprise displaying usage information on the access code usage and/orhelp information, stored in the access control file.

The platform library 204 inputs 314 the obtained access code and thecommand to the security element; in our example to the application 208in the security element. The platform library 204 can include the accesscode into the data part of the command that is issued to the securityelement application 208, but two separate commands can also be used.

Then, in the security element, in our example in the application 208, anaction is performed according to the command, if the access code isapproved by the security element.

The security element, or application 208, returns a response 318 to theplatform library 204. The response 318 can include feedback (or status)information and/or user information. Finally, the platform library 320returns the response 320 to the installed application 200.

It is to be noted that the access code can be input to the securityelement already when the installed application starts in 302. In such acase, the user authentication can be in force until the installedapplication 200 is closed. The access code can also be such that itneeds to be input again for each command. In both cases, the inputaccess code may remain valid for a predetermined time period. The accesscode can be specific for each security element application, or severalsecurity element applications can share a common access code. The accesscode can also be command-specific.

The access control file 206 reading can also be performed when theinstalled application starts in 302. In such a case, the access controlfile 206 need not be accessed for individual commands issued to thesecurity element 106, but the platform library 204 knows the accessconditions and performs the user authentication 312 for the appropriatecommands, for example.

It is possible that the access control file 206, or a reference to it,is returned after the security element application 208 is selected. Inthe security element 106, the application 208, 212 must be selected, asthere can be many applications 208, 212. After the selection, theselected application 208 processes the commands given to the securityelement 106.

In some cases, the platform library 204 does not know that the accesscode is needed, and therefore issues a command to the security element106 without it. Then, the security element application 208 can return anerror message containing the access control file 206 or a reference toit, whereupon the platform library 204 can re-issue the command after ithas examined the contents of the access control file 206 and the accesscode has been obtained according to the access control file 206information.

Even though the invention is described above with reference to anexample according to the accompanying drawings, it is clear that theinvention is not restricted thereto but it can be modified in severalways within the scope of the appended claims.

1. A method for commanding a security element of a mobile terminal, themethod comprising: issuing a command to a platform library of the mobileterminal by an installed application of the mobile terminal; readinginformation from an access control file of the security element by theplatform library; obtaining an access code for the security element froma user according to the access control file information by the platformlibrary; inputting the obtained access code and the command to thesecurity element by the platform library; and performing an actionaccording to the command in the security element, if the access code isapproved by the security element.
 2. The method according to claim 1,wherein obtaining comprises prompting the user for the access code withprompt information stored in the access control file.
 3. The methodaccording to claim 1, wherein obtaining comprises displaying usageinformation on the access code usage stored in the access control file.4. The method according to claim 1, wherein obtaining comprisesdisplaying help information stored in the access control file.
 5. Themethod according to claim 1, further comprising: downloading informationcomplementary to the access control file information from a serveridentified by a network address stored in the access control file. 6.The method according to claim 5, further comprising: validating thecomplementary information with a security certificate stored in theaccess control file.
 7. The method according to claim 5, furthercomprising: storing the complementary information in the securityelement and/or in the mobile terminal.
 8. The method according to claim5, wherein the complementary information is in a different language thanthe access control file information.
 9. The method according to claim 1,wherein the access control file information comprises a code, and theactual information item corresponding to the code is stored in theplatform library and/or in a server identified by a network addressstored in the access control file.
 10. The method according to claim 1,wherein the access control file information comprises access code usageinstructions.
 11. A mobile terminal, comprising a platform library; aninstalled application; a user interface; and a security element;wherein: the installed application is configured to issue a command tothe platform library; the platform library is configured to readinformation from an access control file of the security element, toobtain an access code for the security element from a user via the userinterface according to the access control file information, and to inputthe obtained access code and the command to the security element; andthe security element is configured to perform an action according to thecommand, if the security element approves the access code.
 12. Themobile terminal according to claim 11, wherein the user interface isconfigured to prompt the user for the access code with promptinformation stored in the access control file.
 13. The mobile terminalaccording to claim 11, wherein the user interface is configured todisplay usage information on the access code usage stored in the accesscontrol file.
 14. The mobile terminal according to claim 11, wherein theuser interface is configured to display help information stored in theaccess control file.
 15. The mobile terminal according to claim 11,wherein the platform library is configured to download informationcomplementary to the access control file information from a serveridentified by a network address stored in the access control file. 16.The mobile terminal according to claim 15, wherein the platform libraryis configured to validate the complementary information with a securitycertificate stored in the access control file.
 17. The mobile terminalaccording to claim 15, wherein the platform library is configured tostore the complementary information in the security element and/or inthe mobile terminal.
 18. The mobile terminal according to claim 15,wherein the complementary information is in a different language thanthe access control file information.
 19. The mobile terminal accordingto claim 11, wherein the access control file information comprises acode, and the actual information item corresponding to the code isstored in the platform library and/or in a server identified by anetwork address stored in the access control file.
 20. The mobileterminal according to claim 11, wherein the access control fileinformation comprises access code usage instructions.